There are a number of commercially available products to produce reports from stored data. For instance, Business Objects Americas of San Jose, California, sells a number of widely used report generation products, including Crystal Reports™, Business Objects OLAP Intelligence™, Business Objects Web Intelligence™, and Business Objects Enterprise™. As used herein, the term report refers to information automatically retrieved (i.e., in response to computer executable instructions) from a data source (e.g., a database, a data warehouse, a plurality of reports, and the like), where the information is structured in accordance with a report schema that specifies the form in which the information should be presented. A non-report is an electronic document that is constructed without the automatic retrieval of information from a data source. Examples of non-report electronic documents include typical business application documents, such as a word processor document, a presentation document, and the like.
A report document specifies how to access data and format it. A report document where the content does not include external data, either saved within the report or accessed live, is a template document for a report rather than a report document. Unlike, other non-report documents that may optionally import external data within a document, a report document by design is primarily a medium for accessing and, formatting, transforming and or presenting external data.
A report is specifically designed to facilitate working with external data sources. In addition to information regarding external data source connection drivers, the report may specify advanced filtering of data, information for combining data from different external data sources, information for updating join structures and relationships in report data, and instructions including logic to support a more complex internal data model (that may include additional constraints, relationships, and metadata).
In contrast to a spreadsheet type application, a report generation tool is generally not limited to a table structure but can support a range of structures, such as sections, cross-tables, synchronized tables, sub-reports, hybrid charts, and the like. A report design tool is designed primarily to support imported external data, whereas a spreadsheet application equally facilitates manually entered data and imported data. In both cases, a spreadsheet application applies a spatial logic that is based on the table cell layout within the spreadsheet in order to interpret data and perform calculations on the data. In contrast, a report design tool is not limited to logic that is based on the display of the data, but rather can interpret the data and perform calculations based on the original (or a redefined) data structure and meaning of the imported data. The report may also interpret the data and perform calculations based on pre-existing relationships between elements of imported data. Spreadsheets applications generally work within a looping calculation model, whereas a report generation tools may support a range of calculation models. Although there may be an overlap in the function of a spreadsheet document and a report document, the applications used to generate these documents contain instructions with express different assumptions concerning the existence of an external data source and different logical approaches to interpreting and manipulating imported data.
Confidentiality and security need to be maintained on a number of levels when data sets that contain confidential information are accessed from a database or plurality of databases. Various rules may be applied to specify what information is accessible based on various confidentiality, data protection and freedom of information policies For example, users may have certain role based rights (Role-Based Access Control-RBAC) and these rights to view a record may exist for only specific periods of time. In addition, even when a user has access to the record, certain fields within the record may be maintained as confidential sensitive personal data (SPD) from all but a required subset of the users.
Additionally, the information in a single data source may not in itself be confidential, until it is linked to data within a second (or plurality) of data sources. For example, one data source stores information about the financial or health status of an individual based on a client number and a second data source stores the personal details such as name, address, etc. and can be linked to the first data source by the common client number. The data in the first data source on its own is not necessarily confidential, but when the two data sources are linked, it becomes important to protect the information that is now linked to a specific identity based on the link between the two data sources. This issue of linked data can also exist within a single data source at the table level.
Currently, there are no reporting systems that support rigorous confidentiality constraints. Thus, it would be highly desirable to centralize data access restrictions at the level of the report query so that sensitive data that results from combining data from different sources can be identified and confidentially protected within the resulting report.